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Engineering  Division 


This  report  summarizes  the  state-of-the-art 
of  Value  Engineering.  A  proposed  structure 
for  a  general  value  analysis  technique  along 
with  quantification  of  value  is  presented. 
Based  on  the  proposed  structure  a  general 
method  for  resource  cost  optimization  is 
developed. 
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1.  INTRODUCTION 


This  report  is  the  result  of  effort  performed  under  Phase  I 
of  AF30 (602) -3850.  The  purpose  of  this  report  is  as 
follows : 

a.  To  summarize  the  findings  of  a  value  analysis 
literature  review. 

b.  To  develop  the  logic  of  a  value  analysis  methodol¬ 
ogy  applicable  to  the  conceptual  and  definition 
phases  of  system  development. 

c.  To  develop  a  schedule  for  the  proposed  Phase  II 
program. 

2.  STATE-OF-THE-ART 
2.1  Present  Status 

The  evaluation  of  function  is  the  present  state-of-the-art 
of  value  engineering  theory.  And  the  basic  tool  may  be 
summarized  as  a  series  of  questions  directed  to  function 
evaluation: 

a.  What  is  the  product? 

b.  What  is  the  function  o£  the  product? 

c.  How  well  does  the  product  perform  the  function? 

d.  Are  there  acceptable  alternatives  for  the  design 
of  the  product  for  cost  reduction  and  comparable 
quality? 

This  value  engineering  approach  represents  a  qualitative 
rather  than  a  quantitative  process. 
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This  tool  applied  to  military  value  analysis  takes  the 
following  additional  forms: 

a.  Question  constraints  of  contract.  Does  the 
contract  cover  or  exceed  the  requirement  of 
the  function  of  the  product?  There  are  two 
types  of  requirements  generally  invoked  in 
contracts:  system  operational  requirement  j 
and  military  specification  standards.  System 
operational  requirements  constitute  the  big 
picture  and  are  generally  peculiar  to  the 
system.  These  requirements  are  mission/ 
environment  oriented.  Military  specification 
standards  are  detail  part/performance  require¬ 
ments. 

b.  Question  mission  of  the  product. 

Will  the  product  perform  the  mission  called  for 
in  the  contract  and  specifications? 

c.  Question  constraints  of  the  "abilities/'  e.g., 
reliability. 

Are  the  constraints  of  the  other  "abilities"  com¬ 
patible  with  the  requirements  of  value  for  cost 
reduction? 

d.  Question  alternatives  to  the  design. 

What  alternative  designs  are  possible  to  perform 
the  required  function  of  the  product  within  the 
parameters  of  specifications,  cost,  and  value? 

e.  Question  the  parameters  of  the  function  of  the 
product. 

Will  the  product  perform  the  required  function  with 
the  present  design? 

The  existing  value  methodology  is  primarily  used  as  an 
after  the  fact  cost  reduction  mechanism.  As  a  matter 
of  fact,  considerable  value  analysis  effort  is  performed 
in  the  proposal,  definition,  and  design  phases  of  system 
development;  but  it  is  given  scant  recognition  as  such, 
due  simply  to  the  mensuration  problems  associated  with 
cost  savings. 

There  is  in  value  literature  a  wealth  of  idea  or  genera¬ 
tion  of  alternative  devices  both  of  a  general  nature  and 
even  categorized  by  problem  type;  e.g.,  to  buy  or  make. 


2 . 2  Present  Problems 


The  existing  problems  of  the  value  engineering  discipline 
are  as  follows: 

a.  Need  for  quantitative  criterion  for  value  pointing 
up  difference  between  value  and  cost. 

b.  Need  to  orient  value  analysis  to  total  expected 
resource  cost. 

c.  Need  for  a  feasible  systematic  procedure  for 
evaluation  of  feasible  alternatives. 

d.  Need  to  reorient  value  analysis  to  the  objective 

of  elimination  of  excessive  cost  rather  than  reduc¬ 
tion  in  cost,  e.g.,  do  it  right  the  first  time. 

How  much  can  be  saved  by  decreasing  the  value  of 
the  system  (decreasing  performance  goals,  e.g., 
reliability)? 

e.  Need  to  project  alternatives  into  total  cost 
picture  early  in  the  conceptual  phases  of  system 
development;  thus  a  means  of  making  the  systems 
circuit,  and  packaging  engineer  aware  of  total  cost 
implications. 

3.  THE  DECISION  ENVIRONMENT 
3.1  General 

This  section  is  directed  to  establishment  of  the  fundamen¬ 
tal  concepts,  working  definitions  for  the  value  methodology, 
and  the  program  time  frame  in  which  value  analysis  must  be 
performed.  For  the  purpose  of  this  study,  value  engineer¬ 
ing  is  considered  to  be  that  discipline  directed  to  analysis 
of  how  system  and  equipment  are  related;  whereas,  system 
engineering  is  directed  to  analysis  of  the  relation 
between  mission  ard  the  system.  Thus  as  the  systems 
effectiveness  ar.s?7*t  it*  related  to  the  system  engineer 
so  is  the  value  analyst  related  to  the  design  engineer. 
Pictorially  this  relationship  is  shown  in  figure  3-1. 


System  Value 

Analysis  Analysis 


The  elements  in  common  between  system  effectiveness  and 
system  value  are  the  hardware/software  to  implement  the 
system  and  the  cost  aspects  of  the  hardware/software 
with  related  support  aspects.  Additionally,  the  inter¬ 
face  of  systems  effectiveness  and  system  value  revolves 
about  the  method  of  implementing  the  function.  In 
general,  this  will*  be  hardware,  but  may  be  processes, 
schedules,  etc.,  -  anything  involving  program  schedule, 
total  expected  cost,  or  performance. 

3.2  Value  Engineering  Fundamentals 

3.2.1  General  -  A  general  value  engineering  methodology 
must  meet  certain  specific  requirements;  these  require¬ 
ments  are  as  follows: 

a.  The  desired  method  should  be  useful  for 
objectively  quantifying  value: 

1.  As  a  tool  for  design  decision  through  all 
project  phases. 

2.  In  the  development  of  proposals. 

3.  In  the  evaluation  of  proposals. 

4.  For  monitoring  the  value  level  of  systems/ 
equipment  undergoing  development. 

b.  The  method  should  have  application  to  the  bulk 
of  military  systems,  equipments,  missions,  and 
situations. 

c.  The  method  must  be  technically  valid  and  useful 
in  practice  as  follows: 

1.  It  must  provide  realistic  guidance  for  trade¬ 
offs  between  functional  levels  of  performance 
and  the  costs  of  ownership  and  operation. 
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2.  It  should  take  into  account  the  skill  level  of 
the  average  user  (both  contractor  and  customer) 
and  the  conditions  under  which  it  will  be  used. 

3.  The  data  required,  and  the  actions  to  be 
taken  to  reach  meaningful  decisions#  must  be 
sequenced  and  timed  to  match  normal  program 
phasing. 

4.  The  method  should  be  capable  of  adjustment  to 
maintain  its  validity  in  the  face  of  advances 
in  design,  systems  support  policies,  and 
mission  requirements,  as  well  as  advances  in 
analytical  tools  and  the  quality  of  available 
data. 

5.  The  degree  of  refinement  of  a  model  or 
technique  should  be  compatible  with  the 
basic  accuracy  and  variability  of  the 

data  needed  for  its  use  and  the  sensitivity 
of  the  output  to  variations  in  input. 

6.  The  time  and  cost  required  to  carry  out  the 
procedure  at  any  phase  of  the  development  cycle 
should  be  compatible  with  design  schedules  and 
budgets.  The  cost  of  carrying  out  the  pro¬ 
cedure  must  not  be  disproportionate  to  the 
gains  expected  from  its  use. 

In  the  past  a  number  of  factors  have  militated  against 
meeting  these  requirements  and  care  must  be  exercised  in 
developing  the  approach  without  succumbing  to  the  same 
pitfalls . 

One  pitfall  is  the  failure  to  recognize  that  values  have  an 
existence  at  least  semi-independent  of  cost.  For  instance, 
a  battleship  cut  up  for  scrap  has  far  less  value  than  when 
it  proudly  joined  the  fleet.  Yet  many  more  dollars  have 
gone  into  the  operational  and  scrapping  costs.  A  techno¬ 
logical  breakthrough  can  drastically  reduce  the  cost  of  an 
equipment  without  affecting  the  value  of  the  equipment  at 
all. 
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A  second  pitfall  is  the  not  infrequent  belief  that  all 
value  parameters  can  be  optimized  at  once.  In  most  real 
cases  (given  a  sound  design  to  start  with)  it  is  not 
feasible  to  improve  one  function,  indiscriminately,  with¬ 
out  adversely  affecting  others. 

A  third  pitfall  is  a  widely  held  tendency  to  look  for 
absolute  invariant  value  independent  of  the  particular 
application  and  the  particular  user.  A  glass  of  water 
to  a  man  on  the  desert  has  a  value  quite  different  from 
that  it  has  for  a  man  drowning  in  a  lake.  Obviously, 
elements  of  value  are  desire  or  need,  and  difficulty  of 
acquisition. 

The  elements  of  value  have,  in  present  literature,  been 
combined  to  arrive  at  a  total  figure  of  merit.  This 
assumes  discrete,  mutually  exclusive,  parameters  or 
courses  of  action;  since  this  is  not  always  the  case, 
it  is  necessary  to  use  more  rigorous  methods  of  combina¬ 
tion,  or  to  determine  what  errors  are  introduced  by 
assuming  that  several  parameters  are  independent,  even 
if,  in  fact,  they  are  not. 

It  is  desirable  not  only  to  develop  criteria  for 
measuring  value,  but  also  to  develop  criteria  for 
selection  of  areas  of  high  yield.  This  will  involve 
elements  of  timeliness  and  feasibility  as  well  as  such 
elements  of  yield  as  annual  or  contract  cost  of  producing, 
the  cost  of  operation  and  maintenance,  complexity,  ratio 
of  special  parts  to  standard  parts,  state-of-the-art, 
design  maturity,  and  remaining  useful  life. 

3.2.2  Definitions  -  Like  any  other  prediction/measure¬ 
ment  tool,  value  engineering  can  be  predicated  on  am 
axiomatic  set  of  assumptions,  describing  as  realistically 
as  possible  the  ground  rules  of  the  discipline.  Value, 
for  the  present  purpose,  is  appropriately  viewed  as  the 
utility  of  a  proposed  system  equipment  to  the  user, 
measured  in  terms  of  achievement  of  some  objective 
established  by  the  user.  Thus  value  (of  a  thing)  is  the 
utility  (of  a  thing)  professed  in  achievement  of  an 
objective.  For  military  systems,  this  utility  is 
quantifiable  in  terms  of  performance  capability  measures. 


The  term  objective  may  be  considered  synonymous  with 
the  term  function  as  used  in  value  engineering  litera¬ 
ture. 

Value  engineering  analysis  is  a  quantitative  and  systema¬ 
tic  method  directed  to  the  achievement  of  specified 
performance  objectives  equal  to  or  greater  than  some 
pre-assigned  value  at  minimum  resource  expenditive.  (The 
terms  value  analysis  and  value  engineering  are  treated 
synonymously  in  this  report.)  The  term  system  is  used 
in  this  report  as  an  achievable  objective  specified  in 
terms  of  performance  parameters,  which  are  transformable 
into  hardware  and/or  processes,  and/or  schedules. 

3. 2. 2.1  System  Value  Parameters  -  In  general,  there  are 
two  types  of  system  value  parameters.  These  are  shown 
in  table  3-1.  The  basic  value  parameters  are  as  follows: 

a.  Design  Value  Parameters :  These  parameters  estab¬ 
lish  the  design requirements  imposed  on  the 
system.  The  capability  parameter  is  defined  in 
terms  of  mission  requirements.  Each  proposed 
design  alternative  may  be  predicted  with  respect 
to  satisfying  the  parameter  numeric.  This  would 
be  generally  accomplished  using  modeling  tech¬ 
niques.  Demonstration  testing  may  be  conducted 
to  ensure  satisfaction  of  the  parameter  numeric, 
with  the  exception  of  the  survivability  and 
safety  parameter,  in  which  it  may  be  infeasible. 

b.  Operational  Value  Parameter:  These  parameters 
describe  the  use  value  of'  the  system.  The  design 
and  use  value  parameters  constitute  the  total 
value  to  the  United  States  Air  Force.  Specific 
numerical  description  is  to  be  provided  by  the 
USAF  of  each  design  and  use  value  parameter. 

Value  parameters,  as  defined  above,  satisfy  quantitative 
requirements,  prediction,  and  demonstration  requirements; 


3 


3  -P 

3 

e  c  w 

1 — 1 

3  3  P 

A 

P  g  3 

P  3 

3  3  3 

3  -H 

>1  p  g 

0  P 

3  -H  3 

3 

o  m 

i3  3  H  (J 

3 

3 

3 

0 

3  3  3 

> 

3  &-H  0 

0 

0 

O 

•rl 

0  3  0  0 

p 

ft  3  3  H 

•H 

•H 

•rl  0) 

P 

•rH  0  *rl  -rl 

P  P 

ft  01  -P 

p 

P  to 

P  P 

to 

P  H  p  p 

0  c 

H  3  3 

0)  (0  w 

m  a) 

(0  to 

p 

10  P  (0  to 

ft  a) 

<U  O'  05  0 

ft  0  0) 

0  -rl 

O  0 

p 

0  (0  O  P 

04-0 

3  3  0 

£  0  H 

0  P 

O  O 

0 

0  H  0  3 

3  3 

G  -H  H  H 

to 

P  H  P 

lH  ‘rl 

r- 1 

Qi  rl  rl  H  Q) 

ft  3 

0  3  H 

<u 

■H 

H 

P 

to 

10  6 

ft 

t(J  G  -H  >i 

p 

>i  H 

>1  *H 

>1  0 

3 

>iP  £  3 

3 

P  3  A  A 

m 

rQ  -rl 

rQ  O 

A  ft 

(0 

A  n  A  v 

Q 

3  £  to 

ft 

p 

3 

3 

P 

3  O 

ft 

ft 

ft 

Q 

Eh 

H  P 

(0 

Cost 

iabl 

p 

P 

3  <0 

3 

0  > 

3 

3 

Z 

•rl 

3 

0 

g 

O 

P  P 

0 

•rl 

ft 

H 

•rl  3 

•H 

P 

•r| 

EH 

to  (1) 

P 

3 

3 

3 

H 

•rl  03 

(0 

H 

to 

O1 

3 

z 

3  3 

3 

O 

t — 1 

rH 

ft 

P 

H  H 

01  0) 

O' 

•rl 

3 

3 

3 

1  ft 

U  ft 

•H 

P 

P 

3 

p 

iH 

P 

n  ft 

<  <1) 

to 

A 

to 

3 

to 

o 

X 

Q 

Q 

<U 

3 

3 

3 

3 

0 

•H 

ft 

P  ft 

O 

ft 

H 

S 

Eh 

Eh 

ft 

3 

3 

O 

3  3 

•rl 

P  3 

p 

3 

3  P 

3 

3 

ft  3  3 

N 

P 

*0 

3  ft 

•rl 

3 

3 

3  p 

rH 

3 

ft  oj 

rH 

O'  BJ  rl 

•r| 

3 

^  3 

3 

3  ft  3 

P 

P 

V,  H 

'O 

3  G 

D 

3 

3  3 

3 

p  o'  o 

ft 

*3  'O 

A 

3  -H 

g 

3  Q) 

o 

3  -H  p 

3 

3 

3  3  3 

P 

O  o 

3 

P  -r|  P 

to 

,3  ft 

53 

3  3  3 

O 

ft  P  ft 

ft 

ft 

ft  Eh  O 

>1 

p 

•rl 

rH 

•rl 

A  £ 

5>i 

3  U 

£p 

P 

ft  3 

O 

•rl  >1 

3  3 

3 

3 

>1  HP 

U  H 

>i  3 

3  3 

P  Jp-H  H 

H 

O 

P  P 

rH  P 

>i-H  P  b  H 

3 

P  H 

-rl  (J 

3  3 

P  H  -rl  3  ’H 

3 

3  P 

H  3 

>  P 

•H  H  H  3  A 

O 

3P  >i 

•H  ft 

3 

rl  fl  ’H  -H  3 

•rl 

g  3  P 

b  * 

g  § 

3 

■rl  3  rQ  3  5> 

5* 

P 

R  3  'H 

3  W 

3  3 

O' 

flrl  3  P  -rl 

P 

3 

O  1  H 

3 

P  P 

•rl 

3  H  -H  3  !> 

3 

P 

H  P  -H 

P  3 

3  3 

3 

ft  3  H  -rl  p 

P 

3 

ft  H  ,0 

O  P 

>i  ft 

3 

3  >  3  3  3 

3 

ft 

3  3  0 

P  *r| 

ft 

Q 

U  <  ft  £  ft 

ft 

o 

|Q  w  S  w  3J 

9 


■  w~ 


and,  as  importantly,  represents  utility  of  the  system  to 
the  Air  Force  in  terms  of  achieving  an  objective (s)  . 

3. 2. 2. 2  System  Utilization  Rates  -  The  value  of  the  sys¬ 
tem  is  related  to  the  cost  of  the  system  through  utilization 
rates.  (See  table  3-1.)  The  prime  utilization  rate  is  the 
operational  rate,  viz.,  how  much  is  something  used.  All 
other  rates  are  either  part  of  the  operational  rate  (train¬ 
ing  rate)  or  derivatives  of  it  (maintenance  rates)  . 

3. 2. 2. 3  Dependent  Variables  -  The  system  utilization 
rates,  operating  on  design  and  operation  value  parameters, 
combine  to  determine  both  acquisition  and  support  cost. 

Thus,  for  a  well  defined  system  design  configuration  - 
design  and  operational  value  parameters  specified  along 
with  hardware  implementation  -  the  total  expected  cost  of 
acquisition  and  support  may  be  estimated,  using  the  system 
utilization  rates.  The  system  utilization  rates  are 
intimately  related  to  how  the  system  value  objective  is 
achieved;  that  is,  hardware  alteirnatives.  These  alter¬ 
natives  are  in  turn  related  to  basic  cost  inputs  of 
acquisition  and  support. 

3.2.3  Information  Adequacy  -  At  any  point  in  the  system 
development  cycle,  the  information  upon  which  decisions 
are  based  is  in  the  form  if  estimates.  Greater  detail 
and  accuracy  may  be  obtained  but  only  at  the  expense  of 
time  and  cost  and  perhaps  national  safety.  To  assure 
optimality,  information  accuracy  sufficient  to  assure  that 
one  alternative  is  superior  to  another  is  all  that  is 
required. 

From  the  definition  of  yalue,  and  its  relation  to  total 
expected  cost,  it  is  apparent  that  system  value  can  only 
be  predicted  with  the  same  degree  of  accuracy  as  can  be 
the  basic  value  parameters.  Recognizing;  that  it  is  real 
differences  in  total  expected  cost  which  is  the  principle  cri¬ 
terion,  it  is  also  true  that  information  sufficient  to 
assure  that  one  alternative  is  superior  to  another  is  also 
sufficient  co  assure  that  the  minimum  cost  goal  can  be  achieved. 
This  particular  feature  is  singularly  significant,  in  that 
as  the  hardware  configuration  becomes  more  defined  varia¬ 
tions  in  cost  estimations  for  acquisition  and  support 
decrease.  Further,  for  the  purposes  of  comparing  alter¬ 
natives,  the  points  of  differences  between  alternatives 
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may  be  singled  out  and,  if  necessary,  greater  detail 
information  acquired. 

In  general,  acquisition  costs  are  best  provided  by  the 
contractor  since  this  is  the  source  of  alternatives  and 
basic  cost  inputs.  In  order  to  project  support  cost  as 
a  function  of  design  alternatives  the  USAF  must  be  the 
source  of  operational  parameters  and  specified  cost 
constants.  The  system  utilization  rates  will  be  a  joint 
responsibility.  The  utilization  rates  are  primary 
target  for  sensitivity  analysis. 

3.3  Phases  of  Design  and  Operation 

The  basic  requirements  of  mathematical  model  or  analysis 
technique  is  that  it  be  capable  of  application  in  the 
time  frame  in  which  the  problem  exists  and,  additionally, 
that  it  be  capable  of  utilizing  information  of  limited 
accuracy.  The  refinement  (closeness  of  fit)  of  the 
model  should  be  predicated  upon  exactness  of  the  infor¬ 
mation  processed. 

Throughout  the  conceptual  phases  of  system  development 
decisions  are  made  sequentially  with  increasingly  more 
accurate  estimates  of  system  performance  and  cost.  In 
spite  of  the  relatively  inaccurate  information  avail¬ 
able  in  the  earlier  stages,  decisions  still  must  be 
made  concerning  alternatives,  and  to  ensure  that  the 
proper  alternative  is  selected,  the  methodology  of 
processing  available  information  must  permit  finding 
quantitative  differences  between  alternatives. 

Figure  3-2A  depicts  the  broad  cause  and  effect  relation¬ 
ships  that  in  actual  practice  develops  into  a  concatena¬ 
tion  of  events  that  terminates  in  a  deployed  and  opera¬ 
tional  system.  The  important  features  are: 

a.  As  time  progresses,  the  alternatives  available 
for  subsequent  phases  become  increasingly  con¬ 
strained. 

b.  Changes  in  concept  at  any  phase  can  be  reflected 
in  terms  of  resource  cost  in  subsequent  phases. 
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c.  Input  (requirements)  at  any  phase  may  be 

categorically  related  to  previous  decisions 
or  shown  to  be  relatively  independent. 

Figure  3-2B  depicts  the  same  phases  with  feedback  pro¬ 
vision.  This  feedback  is  simulated  in  that  alternatives 
at  any  phase  are  extrapolated  into  the  terminal  phases 
of  the  system  life  cycle.  The  value  advantage  afforded 
by  simulated  feedback  are  as  follows: 

a.  Minimizes  constraining  requirements  on  sub¬ 
sequent  phases  without  tested  long  range 
effects. 

b.  Permits  relative  evaluation  of  alternatives. 

c.  Permits  sensitivity  analysis  to  be  performed. 
This  type  of  analysis  takes  the  following  forms. 

1.  Determination  of  importance  or  non -impor¬ 
tance  of  a  decision. 

2.  Determination  of  effect  if  a  change  is 
necessitated  in  a  subsequent  phase  of 
life  cycle. 

3.  Point  up  areas  of  high  cost  sensitivity. 

Figure  3-3  provides  a  detailed  picture  of  the  system 
program  phasing.  Opportunity  for  change  exists  at  every 
phase  and  at  every  level  of  system  development.  For 
"change"  (PCP)  read  "value  engineering"  and  the  whole 
story  is  contained  in  one  picture 
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4 .  PROPOSED  STRUCTURE 


4.1  General 

The  methodology  proposed  in  this  report  is  expressly  con¬ 
sistent  with,  and  intentionally  limited  to,  the  existing 
DOD  and  USAF  concept  of  Value  Analysis;  that  is,  achieve¬ 
ment  of  specified  functions  at  minimum  total  expected 
resource  costs  over  the  life  cycle  of  the  system.  The 
program  intent  is  the  development  of  a  technique  which 
will  permit  achievement  of  a  specified  objective  at 
minimum  resource  cost  invested. 


The  important  differences  between  the  orientation  of  the 
proposed  technique  and  conventional  value  analysis  lie  in 
the  areas  of  application,,  The  proposed  technique  is  to  be 
applied  in  the  conceptual  and  definitions  phase;  whereas, 
conventional  value  analysis  is  directed  to  after-the-fact 
design  analysis,  generally  directed  to  minimize  acquisi¬ 
tion  costs,  and  usually  exercised  under  contractual  incen¬ 
tive  types  contracts.  This  latter  approach  is  quite  legitimate 
due  to  the  inability  to  evaluate  consistently  the  savings 
through  value  engineering  efforts  at  earlier  conceptual 
time;  that  is,  how  are  cost  savings  demonstrated  in  the 
conceptual  and  definition  phases. 

The  position  taken  on  this  matter  in  this  program  is,  that 
the  aim  is  not  directed  to  reducing  cost;  but,  stated 
negatively,  to  eliminate  alternatives  requiring  unnecessary 
costs  before  these  costs  are  incurred.  Measured  in  this 
way,  a  product  which  undergoes  significant  .cost  reduction 
in  the  acquisition  stage  is  poorly  designed;  depending 
upon: 

a.  Did  a  preferable  alternative  exist  at  the  time 
the  decision  was  made? 

b.  Does  additional  information  exist  now  which  did 
not  exist  previously? 

c.  Was  the  decision  made  using  the  best  information 
available? 
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d.  Were  the  alternatives  projected  into  total  life 
cycle? 

e0  Were  chance  events  weighed  and/or  explored? 

The  methodology  developed  in  the  following  sections  is 
directed  to  provide  the  least  cost  alternative  through  a 
quantitative  systematic  analysis. 

4.2  Definition  o.:  Objective 

Let  E  designate  a  set  of  parameters  describing  the  system 
effectiveness  of  the  system  under  evaluation. 

E=E(eI/e2,e3. . ,en)  (4-1) 

Let  Eq  designate  the  set  of  parameters  (c^q)  having  the 
minimum  acceptable  performance  numeric  associated  witn 
each  parameter  (greater  than  which  there  is  no  return  in 
effectiveness  for  the  system) .  This  set  of  parameter 
numerics  constitute  the  value  (V)  of  the  system. 

The  value  engineering  criterion  or  objective  now  becomes 

Objective:  Minimize  T=A+S  (4-2) 

Subject  to  E^E0 

D*D0 

where  A  =  cost  of  acquisition 
S  =  cost  of  support 
D  s  delivery  schedule 

DqS=  minimum  acceptable  delivery  schedule. 

This  model  may  be  expressed  also  in  the  form 

MinF (T) =S+>3 ( A-AQ+r3 )  (E -FQ-r^ ) 

+>-(D-D  +r^)  (4”3) 

2  0  2' 
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where: 


E-E^r^O 

E>E0 

D~Vr2=0 

D~Do 

2 

A-A  +r_-0 

A-A. 

0  3 

0 

where: 

18 

is  a  Lagrange  multiplier,  intro¬ 
duced  to  ensure  the  proper 
demensionality  along  with  numerical 
value,  and  r.  is  a  slack  variable 
necessary  to1ensure  that  the  in¬ 
equalities  are  satisfied. 

The  importance  of  equation  4-3  from  the  value  analysis 
viewpoint,  lies,  in  recognizing  that  variations  beyond 
the  minimum  required  (e^)  may  result  in  a  very  real 
cost  reduction.  Figure^-l  illustrates  this  relation¬ 
ship,  where  e..  is  the  specified  numeric  from  the 
systems  studyHSeyond  which  further  improvement  does 
not  contribute  significantly  to  system  effectiveness, 
and  e.  is  the  absolute  minimum  cost  point.  Most 
examples  of  cost  reduction  result  in  increased 
performance,  i.e.,  beyond  requirements.  'For  example, 
a  fringe  benefit  of  cost  reduction  resulted  in  an 
increase  in  reliability  of  30%  of  Class  I  changes  and 
48%  of  Class  II  changes.  This  implies  misdirection 
from  the  existing  definition  of  value  as  well  as 
value  analysis.  The  difficulty  arises  from  the  tacit 
assumption  that  achievement  of  a  quantitatively 
specified  objective  at  minimum  cost  results  in  the 
absolute  minimum  cost. 

4.2.1  General  Value  Function  -  The  definition  of  value 
given  above  obviates  the  problem.-*  of  dimensionality  that 
has  plagued  investigators  seeking  a  value  model  which  per¬ 
mits  establishing  ratios  to  determine  greater  than  or  less 
than  conditions.  The  following  development  shews  the 
characteristics  such  a  function  must  possess  to  satisfy 
a  ratio  test,  viz. 

If 

VT1  (4-4) 

'^7r2<1 

then  Pre^era^^y  to  Vl^l'  etc* 
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Minimum  Cost  Curve 


4- 2.1.1  Requirements  of  a  General  Value  Function  -  Let 

al/a2'*'Jan  ^*e  va^-ues  °f  parameters  describing  a  design 
alternative  and  let  V,  a  function  of  the  parameters,  be 
the  value  of  the  design  alternative.  The  function  V 
( ot,  ,  .  . .  ct^ )  is  to  be  determined  which  expresses  the 

relative  value  vor  absolute)  of  the  design  alternative. 

An  alternate  design  is  described  by  values  of  parameters. 

It  be  required  that  the  ratio 

V(«i'a2 . °n>/v<'3l'*32 . 0n> 

be  independent  of  the  units  of  measurements.  Then  V  must 
be  of  the  form 

a  s. 

^  1  where  s^  is  a  constant  and  independent  of 

The  Si  is  a  measure  of  the  significance  of  ct^. 

The  exponent  may  be  either  positive  or  negative.  The 
values  of  the  exponents  may  be  determined  from 


if  such  a  relationship  can  be  established.  This  yields 
n-1  equations  for  determining  the  n  exponents.  Given  any 
Si,  and  knowing  the  value  of  ki j ,  all  others  may  be  deter¬ 
mined. 


The  model  above  is  predicated  on  the  constancy  of  the 

e.g.,  speed  is  always  twice 
Thus  this  model  forces  a 


relationship  between  Si  and  s- 


(k=2)  as  important  as  cost, 
linear  relationship  among  exponents.  Secondly,  the  model 
dictates  that  an  increment  in  the  value  of  a  parameter  <j^ 
be  independent  of  the  weight  s.  associated  with  that 
parameter. 


4. 2. 1.2  Tfte  Probability  Distribution  Function  -  One  func¬ 
tion  which  satisfies  the  difficulties  of  dimensionality  is 
the  probability  function.  The  basic  requirements  are 
satisfied  if 


a.  The  probability  density  function  is 
p  ( t)  -0 


(4-5) 
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b.  and  the  probability  distribution  function  is 

p (t) dt=l  (4-6) 

oo 

Note  also,  that  the  probability  distribution  function 


/! 


P(t>  tQ)  = 


t  =oc 

p(t) dt 


is,  of  course,  dimensionless 


Thus,  the  probability  function  approach  does  satisfy  the 
dimensionality  difficulties.  The  value  engineering 
structure  proposed  in  the  methodology  developed  in  this 
section  is  completely  compatible  with  the  notion  of  value 
as  a  probability  function.  The  differences  arise  in  that 
it  is  assumed  that  parameter-values  have  been  established 
from  system  effectiveness  trade-off  analysis.  This  per¬ 
mits  treatment  of  the  function  in  disjointed  form  presented 
in  section  4.3. 


4.3  Cost  Analysis 


The  method  of  analysis  is  br,sed  on  the  sequential  decision 
processes,  characterized  by  a  logical  sequence  of  events. 

The  events  are  of  three  types  as  follows: 

a.  Feasible  alternatives 

b.  Chance  events 

c.  Program  schedule 

The  approach  is  commonly  treated  in  literature  as  a  decision 
tree.^ 

This  sequential  decision  approach  is  analogous  to  dynamic 
programming,  in  that  alternatives  which  possess  both 
contingency  events  and  subalternatives  are  evaluated  using 
a  backward  evaluation  process.  This  feature  permits 
significant  computational  reduction  which  otherwise  could 
render  the  technique  infeasible. 
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Each  sequence  in  the  decision  tree  may  be  considered  a 
strategy.  And  associated  with  each  strategy  is  a  resource 
cost.  The  optimum  resource  cost  is  found  by  successively 
evaluating  each  alternative  in  the  backward  sense.  At 
each  common  branch  point,  rolling  backward,  the  more  costly 
alternative  is  eliminated. 

4.3.1  The  Decision  Tree  -  The  technique  to  be  employed  is 
most  easily  grasped  using  the  decision  tree  diagram.  This 
is  shown  in  figure  4-2.  The  circled  (0)  entries  represent 
feasible  alternatives  and  the  boxed  (CD)  entries  represent 
chance  events.  Associated  with  each  chance  event  is  an 
estimated  probability  of  occurrence.  Regardless  of  the 
specific  sequence  chosen,  each  sequence  results  in  a  termi¬ 
nal  event  T;  which,  in  this  case,  represents  a  complete 
definition  of  a  proposed  hardware  configuration  of  the  sys¬ 
tem,  compJ.ete  with  the  cost  (C)  of  the  alternative.  The 
sequential  decision  tree  may  be  considered  the  sequence  of 
increasing  definition  of  the  hardware  design,  the  branches 
represent  alternate  design  approaches  at  successively 
greater  levels  of  hardware  definition. 

4.3.2  Evaluation  of  Design  Alternates  —  The  first  step  in 
the  evaluation  process  is  the  establishment  of  feasibility. 
Specifically,  two  types  of  constraints  must  be  met.  These 
are,  from  the  basic  definition  of  value  of  section  4.2. 


T^«  time  required  to  implement  the  strategy 
b.  E>Eq 

Here  T^  may  be  established  using  a  PERT  project  technique 
and  E  is  established  using  either  the  standard  prediction 
techniques  (reliability,  maintainability,  etc.)  or  a  pre¬ 
diction  model  specifically  developed  for  the  specific  sys¬ 
tem  parameter. 

The  second  step  in  the  process  (having  eliminated  those 
alternatives  which  do  not  satisfy  either  or  both  con¬ 
straints  above)  is  the  estimation  of  the  total  resource 
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cost.  This  may  be  accomplished  using  peculiar  contractor 
cost  accounting  or  PERT/ CO ST  techniques.  Starting  from 
the  terminal  points  having  common  branch  points,  the  more 
costly  alternatives  are  eliminated.  This  procedure  is 
reiterated  until  only  one  alternative  remains.  The  degree 
of  accuracy  involved  in  the  costing  analysis  should  be 
guided  by  the  relative  magnitude  required  to  demonstrate 
that  one  alternative  is  superior  to  the  other. 

4.3.3  Value  Analysis  in  the  Continuous  Time  Domain  -  Many 
design  alternatives  will  be  relatively  simple  decisions 
whereas  others  may  be  more  complex.  The  simpler  evalua¬ 
tions  will  generally  involve  only  acquisition  cost,  there 
being  no  essential  difference  in  value  parameters,  or 
alternately,  only  differences  in  support  cost.  Another 
aspect  which  characterizes  these  simpler  evaluations  will 
be  the  independence  of  subsequent  decisions  involving  the 
system.  However,  in  general,  particularly  of  the  more 
important  decisions,  the  sequential  aspect  of  the  decisions 
will  predominate.  The  question  quite  naturally  arise?  of 
the  feasibility  of  beina  able  to  completely  define  a 
particular  configuration  during  a  preceding  system  concep¬ 
tual  phase.  The  practical  aspects  of  this  question  are 
available  time,  cost,  and  information  adequacy.  Recogniz¬ 
ing  that  as  the  hardware  becomes  more  defined,  decisions 
involving  changes  or  modifications  become  relatively  less 
important  than  the  decisions  made  at  a  previous  stage. 
Further,  only  sufficient  information  to  ensure  that  the 
best  of  the  feasible  alternatives  is  selected  is  required, 
thus  information  is  required  only  sufficient  to  ensure 
dominance  of  one  alternative  to  another. 

4.3.4  Method  of  Application  -  It  is  important  to  recognize 
that  it  is  unlikely  that  equations  will  ever  be 
developed  which  extrapolate  design  value  parameters  in  con¬ 
junction  with  operational  value  parameters  into  exact 
support  costs.  However,  from  the  viewpoint  of  value  analy¬ 
sis,  it  is  not  necessary  to  possess  such  comprehensive 
equations.  What  is  necessary  is  the  ability  to  evaluate 
alternatives  via  cost/performance  differences. 
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The  cost  methodology  aspect  of  value  analysis  is  of  primary 
significance,  since  any  unrequired  sophistication  and/or 
information  and  documentation  may  offset  advantages  offered 
by  the  technique. 

The  proposed  approach  is  advantageous  in  that  it  permits  individual 
contractors  to  use  their  own  cost  accounting  systems.  The 
only  requirement  is  the  ability  to  differentiate  between 
alternatives  as  measured  by  acquisition  and  support  cost. 


4.4  Detailed  Cost  Procedure 

The  total  cost  (T)  of  a  system,  equipment,  etc.,  can  be 
represented  by 

T=A+S  (4-7) 

where 

A=the  cost  of  acquisition 

S=the  cost  of  operation  and  support 

The  cost  £  is  based  on  the  expected  lifetime  cost.  Figure 
4-3  shows  the  basic  cost  model  which  has  to  be  evaluated. 
Each  element  would  ordinarily  be  evaluated  to  obtain  the 
total  cost.  For  purposes  of  reaching  a  decision  or 
whether  to  accept  a  particular  alternative,  differences  in 
total  cost  are  employed.  Thus,  it  is  unnecessary  to 
evaluate  equivalent  elements  of  the  two  alternatives  when 
considering  which  one  of  two  to  choose.  It  is  necessary 
only  to  evaluate  the  elements  that  are  pertinent  to  a 
particular  decision. 

Let 


T.*total  cost  of  the  first  alternative 
T2*total  cost  of  the  second  alternative 


the  difference  in  total  cost  (ATj  is  represented  by 

(4-8) 


AT2.1-VT1 
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Total  Coat 1  | Total  Coat 


where  elements  of  cost  common  to  the  first  and  second 
alternatives  need  not  be  considered  if  they  are  equal. 

If  the  quantity  AT2  1  is  negative,  it  means  that  the 
second  alternative  is  less  costly.  If  positive,  it  means 
that  the  first  alternative  is  the  correct  choice,  viz,, 
less  costly. 

Once  two  alternatives  have  been  compared,  the  one  yielding 
the  lesser  cost  advantage  is  dropped  from  further  considers 
tion.  Successive  alternatives  are  devised  and  matched 
against  the  current  alternative  that  has  greater  cost 
advantage, 

4,4,1  Cost  of  Acquisition  -  The  elements  to  be  considered 
include  all  charges  which  may  arise  from  the  design, 
development,  fabrication,  and  installation  of  the  equip¬ 
ment. 

Particular  attention  should  be  paid  to  items  which  mark 
the  differences  between  otherwise  similar  alternatives. 
Among  these  may  be: 

a.  Built-in  fault  isolation  features 

b.  Special  test  equipment 

c.  Special  tools 

d.  Facility  of  manufacture 

Differences  in  research,  development,  design,  or  hardware 
costs  should  be  considered  where  they  constitute  a  signif¬ 
icant  difference  among  the  alternatives.  Differences  in 
requirements  for  government  furnished  equipment  (GFE) 
should  also  be  established.  In  any  case,  refined  estimates 
of  costs  are  justified  only  when  the  alternative,  or  group 
of  alternatives,  has  cost  or  orher  advantages  which  make 
it  a  good  candidate  for  selection. 

Cost  of  acquisition  (A)  can  be  represer ted  by: 

a-Vcf+ci+ch+YVcl  <4"9> 
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where 


CD=cost  of 
Cp=cost  of 
Cj=cost  of 
CM=  cost  of 
CT=cost  of 
Cx=c°st  of 
CL=cost  of 


design 

fabrication 

installation 

manuals 

test  equipment 

tools  and  fixtures 

line  item  documentation 


These  costs  have  been  tentatively  identified  in  section 
three  and  will  be  considered,  and  further  refined,  .in 
phase  II  of  the  program. 


4.4.2  Cost  of  Operation  and  Support  -  The  cost  of  opera¬ 
tion  and  support  (S)  is  represented  by 

S=C0+Cf+Cd+Cy  (4-10) 

where 

r  =rnsf-  at*  /^rrran  i  7.7\  t  i  r>r> 

_o  -  --  — => - 

Cf=cost  at  field 
Cd=cost  at  depot 
Cy=cost  at  factory 

4. 4. 2.1  Cost  at  Organization  -  The  cost  at  organization 
(Cc)  is  represented  by 

co*”cm+cof+cos+cot  <4-H) 

where 

Com*cost  of  personnel 
C0f*cost  of  facilities 
Cos-cost  of  spares 
Cot-cost  of  transportation 

4. 4. 2. 2  Coat  at  Field  -  The  cost  at  field  (Cf)  is 
represented  by 


Cf-Cfm+Cff+Cfs+Cft 


(4-12) 
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where 


Cf^  =  cost  of  personnel  at  field 
Cff  =  cost  of  facilities  at  field 
Cfs  =  cost  of  spares  at  field 
Cf t  -  cost  of  transportation  at  field 

4. 4.2. 3  Cost  at  Depot  -  The  cost  at  depot  (C^)  is 
represented  by 

cd  =  Cdm+Cdf+Cds+Cdt+Cdu+Cl  (4-13) 

where 

cdm  =  cost  personnel  at  depot 
cdf  =  cost  °f  facilities  at  depot 
Cds  =  cost  of  spares  at  depot 
cdt  *  cost  of  transportation  at  depot 
cdu  =  cost  of  utilities  at  depot 
-  cost  of  line  item  at  depot 

4. 4. 2. 4  Support  Cost  at  Factory  -  The  total  cost  of 
factory  (Cy)  will  vary  so  much  with  the  type  of  labor  to 
be  employed  that  no  attempt  will  be  made  io  estimate  the 
cost. 


Repair  at  factory  is  rare,*  however,  special  conditions  may 
make  it  appropriate  in  some  cases.  Repairs  may  be  made  at 
the  factory  rather  chan  at  the  depot  for  several  reasons. 
Most  instances  are  accounted  for  by  one  of  the  following; 

a.  Rare  skills  and/or  expensive  special  test  equip¬ 
ment  are  required  to  perform  maintenance,  e.g,, 
gyroscopes  and  some  other  sealed  assemblies. 

b.  Demands  for  maintenance  exceed  capacity  at  depot 
(as  limited,  for  example,  by  employment  budget) 
and  factory  charges  are  not  far  in  excess  of  depot 
costs . 
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In  both  of  these  instances,  costs  associated  with  perform¬ 
ing  the  work  at  the  factory  generally  should  be  about  the 
same  or  less  than  would  be  incurred  if  the  work  were  done 
at  the  depot.  Otherwise,  the  work  should  be  scheduled  for 
performance  at  the  depot. 

In  general,  factory  maintenance  is  not  planned  as  an  inte¬ 
gral  part  of  maintenance  policy.  Requirements  for  self- 
sufficiency  of  the  military  generally  preclude  planning 
on  factory  or  other  contractor  maintenance  of  critical 
equipment.  Where  it  might  be  planned  (as  in  a  above) 
experience  and/or  estimates  from  the  probable  contractor 
should  provide  adequate  cost  figures  for  use  in  comparisons 
Detail  costing  becomes  less  important  in  fixed  price  con¬ 
tracts,  favored  type  today,  as  contrasted  to  cost  plus 
fixed  fee  and  similar  types  common  in  the  past.  Conse¬ 
quently,  no  detail  breakdown  will  be  made  for  estimating 
costs  of  factory  maintenance  in  the  few  situations  where 
it  is  applicable. 

4.4.3  General  Evaluation  Procedure  -  Figure  4-4  illus¬ 
trates  a  tabular  procedure  for  evaluating  each  element  of 
the  cost  model.  Provision  is  made,  in  figure  4-4,  for  the 
evaluation  of  two  alternatives.  Only  the  elements  that 
change,  from  one  alternative  to  the  other,  will  be  required 
Once  two  alternatives  have  been  evaluated,  the  one  yielding 
a  cost  advantage  is  retained,  and  the  other  alternative  is 
no  longer  considered. 


Figur' 


5 .  SUMMARY 


The  proposed  value  analysis  technique  developed  in 
sections  3  and  4  has  been  shown  to  possess  the  following 
characteristics : 

a„  Quantification  of  value  consistent  with  estab¬ 
lished  USAF  specification  of  system  utilization. 

b.  Value  parameters  which  are  predictable  and 
measurable . 

c.  Systematic  method  of  quantitative  analysis  which 
permit  practical  optimization  in  the  least  cost 
sense  consistent  with  system  value. 

d.  Technique  structure  which  permits  design  tradeoff 
of  discrete  alternatives  relating  to  cost  and  sys¬ 
tem  value  parameters. 

e.  Method  of  cost  analysis  which  permits  optimization 
with  respect  to  total  cost  and  is  consistent  with 
both  design  and  operational  value  parameters. 

f.  Method  of  cost  analysis  based  on  difference 
principles  which  permits  decisions  through  domi¬ 
nance  of  one  alternative  to  another. 

g.  General  method  of  analysis  which  permits  cost  in 
time  and  singling  out  areas  significant  cost 
differences  between  alternatives. 
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PLAN  FOR  PHASE  II 


6.1  General 


The  structure  of  value  as  developed  in  section  4  indicates 
the  most  fruitful  areas  of  exploitation  of  the  methodology. 
This  comes  about  primarily  as  a  result  of  the  strict  causal 
relations  between  system  value  and  the  total  expected  cost 
differences.  Consequently,  the  major  direction  to  be 
taken  in  the  Phase  II  will  be  a  general  refinement  and 
expansion  of  the  value  analysis  methodology.  (See  figure  6-1' 

6.2  Structure 


The  areas  of  refinement  and  expansion  will  be  as  follows: 

a.  Detailed  breakout  for  acquisition  cost  specifi¬ 
cally  related  to  conceptual  and  definition  phases. 

b.  Detailed  breakout  for  support  cost  specifically 
related  to  conceptual  and  definition  phases. 

c.  Expansion  and  refinement  of  technique  to  handle 
chance  events.  Some  work  has  already  been  done 
in  this  area  but  involves  making  estimate,  of 
probability. 

d.  Development  of  causal  relations  between  value 
parameters,  system  utilization  rates,  and  total 
cost  differences. 

e.  Development  of  detailed  information  requirements 
to  be  supplied  by  the  USAF  for  support  cost 
analysis.  This  would  include  a  delineation  of 
deployment  and  self-sufficiency  constraints. 

6.3  Validation 

RCA  proposes  to  validate  the  value  technique  developed 
under  Phase  I  of  the  contract  in  the  following  manner. 
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Structure 
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6.3.1  Establishment  of  Errors  -  Establishment  of  error 
sources,  anticipated  error  magnitude,  and  error  bounds 
on  the  following  aspects  of  the  technique. 

a.  Capability  of  projecting  design  alternatives 
accurately  into  the  support  cost  differences. 

b.  Capability  of  controlling  acquisition  cost. 

c.  Capability  of  forming  a  near  minimum  cost  initial 
proposal . 

d.  Capability  of  performing  within  schedule  con¬ 
straints. 

e.  Capability  of  singling  out  tradeoffs  between 
design,  manufacturing  and  support  costs. 

6.3.2  Mode  of  Application  -  RCA  proposes  to  use  at 
least  the  following  exampfes  to  illustrate  the  mode  of 
application  of  the  techniques. 

a.  Production  Design  Phase  -  Selection  of  wire 
wrapping  process  for  MINUTEMAN. 

b.  Program  Definition  Phase  -  Selection  of  real 
time  computer  redundancy  configuration  for 
complex  mobile  missile  system. 

c.  Proposal  Phase  -  Several  examples  of  cost 
minimization  in  a  competitive  environment, 
incorporating  cost  control  check  points  in 
sequential  phases,  and  involving  tradeoffs 
between  engineering  and  manufacturing. 

6.3.3  Discussion  -  Although  the  validation  above  will  not 
constitute  a  substitute  for  several  test  vehicles  followed 
through  the  entire  life  cycle,  it  will  establish  feasibi¬ 
lity  of  implementation.  The  proposed  approach  to  valida¬ 
tion  is  due  to  lack  of  information  on  previous'.'/  designed 
systems;  plus,  the  inability  to  project  the  requirements 
for  testing  and  field  use  for  systems  that  ar^  presently 
in  the  design  stage. 

Approaching  the  validation  in  the  manner  proposed  will 
test  the  technique  for  selective  application  acrosj 
product  lines  along  with  decision  making  capability 
as  related  to  program  phasing. 
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6. 3.4  Critical  Points  -  The  critical  points  of  the  vali¬ 
dation  will  include  tfie  following: 

a.  Information  availability  and  adequacy  relative  to 

1.  Design  value  parameter 

2.  Operational  value  parameter 

This  will  provide  a  critique  of  information 
adequacy  as  a  function  of  the  conceptual  phases 
considered. 

b.  Computational  problems  in  technique  application. 

c.  Ability  to  project  cost  differences  in  both 
acquisition  and  support  as  a  function  of  alterna¬ 
tives.  This  will  permit: 

1.  Testing  for  the  principle  of  dominance  among 
alternatives. 

2.  Singling  out  sources  of  error  in  cost  esti¬ 
mation. 

d.  The  quantitative  predictability  and  measurability 
of  the  system  value  parameter  will  be  evaluated. 

6.4  Implementation 

The  scheduled  validation  of  the  developed  value  analysis 
methodology  will  constitute  a  practical  test  of  the  imple¬ 
ment  ability  of  the  technique.  The  proposed  technique  is 
prima  facie  implement ?ible  from  the  basic  structure,  given 
the  basic  information  required  for  decision  making. 
Anticipated  difficulties  will  invariably  pivot  about 
information  availability  and  associated  uncertainty. 

The  key  to  successful  application  of  the  technique  will 
rest  on  the  detection  of  potential  co3t  affected  areas 
coupled  with  the  ability  to  eliminate,  systematically, 
the  more  expensive  altern;**"5  ves.  The  proposed  structure 
permits  the  latter.  The  first  point  will  be  satisfied, 
in  the  second  phase  of  the  program,  by  providing  detailed 
cost  element  breakouts  and  cost  projection  techniques. 
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APPENDIX 


LITERATURE  SEARCH 


1 .  INTRODUCTION 

The  bibliography  included  is  a  selective  one  representing 
the  present  state-of-the-art  in  value  engineering „  During 
the  literature  search  over  100  documents  were  examined;  of 
these,  the  seventeen  documents,  included  in  the  bibliography, 
were  considered  to  represent  the  thinking  currently  in  vogue 
with  value  engineers  and  represent  the  state-of-the-art. 

2.  SHORTCOMINGS  OF  STATE-OF-THE-ART 

Several  shortcomings  permeates  essentially  all  literature 
reviewed.  These  are; 

a.  Value/ Job  Definition:  Generally  value  is  defined 
loosely  as  getting  the  job  done  at  least  cost;  how¬ 
ever,  invariably  there  is  only  a  loose  tie  with 
how  the  job,  as  described,  relates  to  the  value  of 
the  end  product,  viz.,  accomplishment  of  mission. 

b.  Support  cost  and  extrapolations  to  support  cost  is, 
at  best,  given  only  lip  service.  There  has  been 
no  real  attempt  to  evaluate,  systematically,  total 
resource  cost  variation  as  a  function  of  design/ 
development  alternative  selection. 

c.  Most  examples  of  cost  reduction  result  in  ircreased 
performance,  i.e.,  beyond  requirements.  This 
implies  misdirection  from  the  existing  definition  of 
value  as  well  as  value  analysis.  The  difficulty 
arises  from  the  tacit  assumption  that  achievement 

of  a  quantitatively  specified  objective  at  minimum 
cost,  results  in  the  absolute  minimum  cost. 

Figure  4-1,  in  the  text,  illustrates  this. 
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d.  Value  engineering  techniques,  as  they  exist  now, 
are  exclusively  oriented  to  acquisition  or 
operation  phases  rather  than  the  conceptual  or 
definition  phases. 


39 


unclassified 


Security^GaMifjeflttefj^ 


DOCUMENT  CONTROL  pm  •  RAD 


T  QRIOINATINC  ACTIVITY  fCo(por*l.  ou«iom' 

Radio  Corporation  of  America 

RCA  Service  Company  Division 

Alexandria,  Va.  2231L 

Iff.  Hf>OPT  lieuniTY  C  LAfSIffIC  A  TlON 

UNCL 

ib  GROUP 

1  REPOBT  TITLE 

Criteria  for  Value  Engineering,  Fhase  I,  Feasibility  Study 

4.  DESCRIPTIVE  NOTfS  (Typ*  ol  f*port  «o4  Iro/m.Iv.  4tf») 

Iuterim  Report  Jul  1965-Nov  1966 

t  4UTHORf;.J  f /.«»(  nas  .,  ttm  ntmt.  InjllpO  ' 

Purvis,  R.  E. 

McLaughlin,  R.  L. 

».  *|tfOR  pate 

February  1966 

39  None 

f-  ff-  CONTRACT  OR  Op  AN  T  Np. 

AF30(  602) -3850 

«  Task  Nr. 

551901 

<• 

ORIGINATOR1*  REPORT  NUMSf RflJ 

M  giJ'UjFR^RJPORT  NOfS;  (Any  pthtt nvmbprp  AV  -y  b»  a.ilsnxl 

RADC-TR-65-^75 

10  avaii:*bility/l1kiiT*ti«m  ingTicii 

Distribution  of  this  document  is  tu 

nlimitci. 

I  SUPPLEMENTABY  NOTH 


11.  IPOBSORIMO  MUITARY  ACTIVITY 

Reliability  Branch 
Engineering  Division 

Rome  Air  Development  Center,  GAFB,  N.  Y. 


:j  ROSTRA' 


This  report  t-umrari zes  the  state-of-the-art  of  Value  Engineering.  A 
proposed  structure  for  a  general  value  analysis  technique  alo~g  with 
quantification  of  value  Is  presented.  Based  on  the  proposrd  structure 
a  general  method  for  resource  coot  optimization  is  developed. 


DD  Mi-,.  1473 


UNCLASSIFIED 


Sacu.itv  Classification 


Security  Classification 


System/Equipment 

Design 

Cost/Effectiveness 
Performance 
Operations  Research 
Value 


LINK  B  j 

|  LINK  C 

hole 

;  *T  1 

1  ROLE  1 

V*  T 

1.  ORIGINATING  ACTIVITY:  Enter  the  name  end  addreia 
of  the  contractor,  subcontractor,  grantee,  Department  of  De¬ 
fense  activity  or  other  organization  ('corporate  author)  issuing 
the  report. 

2a.  REPORT  SECURITY  CLASSIFICATION:  Enter  the  over¬ 
all  security  classification  of  the  report.  Indies**  whether 
"Restricted  Data"  is  included.  Marking  la  to  be  in  accortR 
ance  with  appropriate  security  regulations. 

2b.  GROUP:  Automatic  downgrading  is  specified  in  DoD  Di¬ 
rective  5200. 10  and  Armed  Forces  Industrial  Manual.  Enter 
the  group  number.  Also,  when  applicable,  show  that  optional 
markings  have  been  used  for  Group  3  and  Group  4  as  author¬ 
ized. 

3.  REPORT  TITLE:  Enter  the  complete  report  title  in  all 
capital  letters.  Titles  in  all  cases  should  be  unclassified. 

15  a  meaningful  title  cannot  be  selected  without  classifica¬ 
tion,  show  title  classification  in  all  capitals  in  parenthesis 
immediately  following  the  title. 

4.  DESCRIPTIVE  NOTES  If  appropriate,  enter  the  type  of 
report.  interim,  progress,  summary,  annual,  or  final. 

Give  the  inclusive  dates  when  a  specific  reporting  period  is 
covered. 

5.  AUTHOR(S):  Enter  the  nimefa)  of  authorfs)  as  shown  on 
or  in  the  report.  Entet  last  nar.e,  first  name,  middle  initial. 

If  military,  show  rank  and  branch  of  service.  The  name  of 
the  principal  author  is  an  absolute  minii.ium  requirement. 

6.  REPORT  DATE.  Enter  *he  date  of  the  report  as  day, 
month,  year;  or  month,  year.  If  more  than  one  date  appears 
on  the  report,  use  date  of  publication. 

7a.  TOTAL  NUMBER  OK  PAGES:  The  total  page  count 
should  follow  normal  pagination  procedures,  i.e,,  enter  the 
number  of  pegea  containing  information. 

76.  NUMBER  OF  REFERENCES  Entar  the  total  number  of 
references  '  tied  in  tht  raport. 

8a.  CONTRACT  OR  GRANT  NUMBER:  If  appropriate,  enter 
the  applicable  number  of  the  contract  or  grant  under  which 
toe  report  wa»  smitten, 

86,  8t,  &  Id  PROJECT  NUMBER:  Enter  the  eppropriate 
military  department  identification,  such  as  protect  number, 
subproject  number,  system  numberu,  teak  number,  etc. 

9e.  ORIGINATOR’S  REPORT  NUMBER(S)  Enter  the  offl- 
cial  report  numbei  tv  which  the  document  will  be  identified 
end  controlled  b>  the  originating  activity.  This  number  must 
be  unique  to  this  report. 

»b.  OTHER  REPORT  NUMBER! S):  If  the  report  hoa  been 
assigned  any  other  report  numbers  f either  fc>  (be  originator 
or  by  the  sponsor;,  alto  enter  this  Humberts). 

10.  AVAILABILITY 'LIMITATION  NOTICES  Enter  an  >  I  im¬ 
itations  un  further  dissemination  of  the  report,  other  then  'hose 


INSTRUCTIONS 


Imposed  by  security  classification,  using  standard  statements 
such  «s: 

(1)  "Qualified  requesters  may  obtain  copies  of  this 
report  from  DDC" 

(2)  "Foreign  announcement  and  dissemination  of  thia 
report  by  DDC  is  not  authorized.” 

(3)  "U.  S.  Government  agencies  may  obtain  copies  of 
this  report  directly  from  DDC.  Other  qualified  DDC 
users  shall  request  through 


(4)  "U.  S.  military  agencies  may  obtain  copies  of  thia 

report  directly  from  DDC  Other  qualified  user, 
shall  request  through 


(5)  "All  distribution  of  this  report  is  controlled.  Qual¬ 
ified  DDC  users  shall  request  through 


If  the  report  has  been  furnished  to  the  Office  of  Technical 
Services,  Department  of  Commerce,  for  sale  to  the  public,  indi¬ 
cate  thia  fact  and  enter  the  price,  if  known. 

1L  SUPPLEMENTARY  NOTES:  Use  for  additional  explana¬ 
tory  notes. 

12.  SPONSORING  MILITARY  ACTIVITY:  Eiger  the  name  ol 
the  departmental  project  oKice  or  laboratory  sponsoring  (pay 
:ng  for)  the  research  and  development.  Include  address. 

13  ABSTRACT:  Enter  an  abstract  giving  a  brief  and  factual 
summary  of  the  document  indicative  of  the  report,  even  though 
it  may  also  appear  elsewhere  in  ihc  bodt  of  the  technical  re¬ 
port.  If  additional  apace  it  required,  a  continuation  sheet  snail 
be  attached. 

It  is  highly  desirable  that  the  abstract  ut  classified  reports 
'  t  unclassified.  Each  paragraph  of  the  abstract  shall  and  with 
.  indication  -*f  the  military  i.ecutity  classification  of  the  in¬ 
formation  in  the  paragraph,  represented  as  (T$).  fS>.  fC),  er  <V) 


There  it  no  limitatio* 

ever,  the  suggested  lengv 


n  the  length  of  the  abstract.  How- 
<  from  ISO  to  225  word*. 


14  KEY  WORDS:  Key  words  arc  technically  meaningful  tanas 
or  short  phrases  thai  chars,  t»rtze  a  report  and  may  be  ueed  ea 
index  entries  for  cataloging  the  report.  Key  words  must  be 
selected  so  the!  no  security  .  Uas.I'cadon  is  required  Ids  nil 
fiers.  such  as  equipment  model  designation,  trade  naiae,  military 
peejeci  code  name,  geographic  location,  may  tw  u*#d  as  key 
words  but  will  be  followed  by  en  Indication  of  technical  con¬ 
test.  The  assignment  of  link*,  rules,  and  weight*  I#  optional. 


